Here, I updated RUMSessionScope tests to transitively cover all cases in RUMOffViewEventsHandlingRule used internally. I took this approach instead of abstracting RUMOffViewEventsHandlingRule through interface and mocking it for tests. I wanted to optimise code readability in RUMSessionScope, even if the cost was more effort in fuzzy testing.

I added this missing test, because now RUMWithCrashContextIntegration is injected through DI and we're able to configure the mock.

Since a event cannot be sent outside of a session, shouldn't we apply this rule only if we have a session state? this would mean making the state non-optional.
And if it's more convenient to keep it optional, why not dropping the event if the session state is nil?

This (sessionState: nil) is used later in #695 to decide on handling crashes which occurred as the very first event in the app. For example, in case of:

Datadog.initialize(
   ...
)

fatalError("crash")

we don't have RUMSession yet created, so its persisted (through CrashContext) state will be nil.

I've spent a while trying to model the minimal information we need to persist in CrashContext for differentiating crashes during app launch in foreground vs background and resulted with this RUMSessionState. If you can find a better model, I'd be happy to adopt it and simplify things 🙂 🙌! I'm all for consistency here, making things optional just for convenience might be error-prone.

I think the model is great and simplifies the rule definition!

In the next PRs, will the RUMSessionState.sessionUUID will be leveraged somehow for other purposes than checking if it's sampled ou?
I'm wondering if we could do something like:

internal struct RUMSessionState: Equatable, Codable {
    let isSampled: Bool
    let isInitialSession: Bool
    let hasTrackedAnyView: Bool

    static let `default` = RUMSessionState(isSampled: false, isInitialSession: true, hasTrackedAnyView: false)
}

This way, we could make the state non-optional and clarify the statements in this init?

In the next PRs, will the RUMSessionState.sessionUUID will be leveraged somehow for other purposes than checking if it's sampled out?

Now I think that in #695 I forgot to handle the case which I spotted when designing RUMSessionState 😰. Indeed, it may look now that sessionUUID is not necessary and we don't use it in #695 now.

The plan was to use sessionUUID in this scenario:

• 1/ SDK has Background Events Tracking enabled and views instrumentation turned ON;
• 2/ It tracks some views, leading to updating lastRUMViewEvent in CrashContext;
• 3/ Then the app is sent to background (so it stops the recent view);
• 4/ No other event occurs in the background except the crash.

In such case, because there is no active view (3) and the app crashed in background (4) we should send the crash in "Background" view (1). No additional sampling should be considered and both crash and its "Background" view should be sent to the sessionUUID used for tracking other views in this session (2).

That said: no, isSampled: Bool wouldn't be enough for RUMSessionState - we also need to know its uuid for above case ☝️. Knowing that .nullUUID means "not sampled", it also simplifies few more edge cases.

I will update next PR (#695) with necessary logic for handling this case 👍. Otherwise the RUMSessionState persistence in CrashContext doesn't make sense at all.

Makes sense then 👍